A diverse range of communication systems are in use today enabling communication between two or more entities, such as user equipment and/or other nodes associated with the system.
Communication systems proving wireless communication for user terminals or other nodes are known. An example of a wireless system is a public land mobile network (PLMN). A PLMN is typically a cellular network wherein a base transceiver station (BTS) or similar access entity serves user equipment (UE) such as mobile stations (MS) via a wireless interface. The operation of the apparatus required for the communication is usually controlled by one or more control entities, which themselves may be interconnected. One or more gateway nodes provide for connecting the PLMN to other networks. Examples of other such networks are another cellular network, a public switched telephone network (PSTN) and packet switched data networks such as an IP (Internet Protocol) based network. The communication between the user equipment and the other elements of the communication system, are based on an appropriate communications protocol, which defines the “rules” under which communication is handled in the system.
In the current third generation (3G) wireless system, there are defined various servers for the handling of different communication services for mobile users. These include servers that provide call state control functions, known as CSCFs. Control functions may also be provided by entities such as a home subscriber server (HSS) and applications by various application servers. The HSS is typically for permanently storing the user's profile and used during authentication. For example, in the Release 5 architecture for 3G, as specified by the 3rd Generation Partnership Project (3GPP), these entities can be found located in the IP-Multimedia Subsystem (IMS).
The IMS network may sit at the hub of the 3G architecture, supporting an IP based network that handles both traditional voice telephony and multimedia services. The 3GPP has chosen Session Initiation Protocol (SIP) as a core session signalling protocol for 3G networks. SIP has been developed by the Internet Engineering task Force (IETF). Those interested can find the 3GPP specification 24.229 describing the IMS network's basic operation from an SIP perspective titled “IP Multimedia Call Control Protocol based on SIP and SDP” at http://www.3gpp.org/ftp/Specs/Latest-drafts/24229-201.zip. SIP is a request/response style protocol, in the sense that for every message sent from a source, there is an associated response from the destination confirming receipt of the sent message. (The acknowledgement ACK message is a special case to which no response is sent)
For example, in a 3G network, when a user first switches on his mobile terminal, he must register his user ID or address with the network before allowing the terminal to fully connect. This is done by sending an SIP ‘REGISTER’ message from the terminal to the IMS, which includes details of the users address. The IMS receives and processes this information using a serving call state control function (S-CSCF), which in this context is referred to as the “registrar”. The REGISTER message is only used to provide mapping between a user's alias and contact address e.g. mapping alias sip:mikko.lonnfors@sonera.com to a terminal's IP address. The IMS acknowledges the registration by sending a suitable acknowledge message (e.g. 200 OK message) in accordance with SIP. Subsequent registrations also take place (re-‘REGISTER’) whenever the preceding registration has expired or is expiring, or when there is a change in the status of the user. When a user wishes to set up a session with another user, such as a voice call or messaging session (there is another way of sending messages i.e. with a SIP MESSAGE and in this case session establishment is not required), the session negotiation will also be performed under SIP.
Application servers (AS) may supply services via the IMS such as instant messaging, presence, local traffic reports, and conferencing facilities. An AS may reside within the IMS network, or outside of it. Typically the AS is external when the service supported is provided by a third party
One specific example of status information is presence information. Users or application servers subscribing to a presence service can determine the ability and availability of another user e.g. to accept a call (depending on the equipment and service provider) among other presence features/attributes. However, in systems supporting SIP, presence can assume a variety of indicators such as ‘in the office and available for all calls’, ‘at home and available for private calls only’, and ‘busy in call’ (or at least appear that way). Thus presence information allows a user to ascertain the availability of another user before attempting to make a call. The presence service can provide more than just information such as available/not available. It can contain visual, animated or sound elements and can describe various issues for example related to a game session.
This presence service which is being standardised in OMA 8 (open mobile alliance (www.openmobilealliance.org)), 3GPP and IETF is gaining more and more attention. It is expected that the number of presence aware applications will increase in future. As the number of applications increase it also increases the amount of presence information. From the receiving terminal perspective the increase of information poses a challenge as to how to treat the presence information i.e. which parts of the presence information are relevant to which application(s). A terminal may run one or more applications. For example, the terminal can run a dynamic phone book application and a games application.
In the current IETF and 3GPP models, a tuple structure is used. The tuple contains a ‘random’ TUPLE ID which does not have any semantics i.e. it cannot be used describe the purpose of the tuple. In each tuple there can be several attributes. Moreover, different tuples may have attributes that have same name but are intended to be used/interpreted differently depending on the sending/receiving application. For example the presence information can contain two tuples (one for games and one for a dynamic phonebook (DPB)) and each of these tuples may contain a status field. The dynamic phone book may have been designed to understand status values: available, discreet, not available whereas the game may be designed to understand status values: shooting, dead, paused, lost. As can be seen from this example, the status fields have to be delivered to the correct application if they are to have the correct meaning. This is a problem when a terminal has two or more applications. This is also a problem even if the receiving terminal has only one application and sending terminal or presentity has multiple ones. If the data as provided in the example is delivered to the terminal having only e.g. DPB, the receiving terminal needs to be able to determine which tuple was intended for the DPB application.
Currently, there is no mechanism to pass the information to the correct applications other than for each application to check each tuple and see if the status values have any meaning for the application. In other words a trial and error approach is adopted. However, this creates uncertainty as to correctness of the information. This is because in some cases even it the value may be the same for an attribute, it may be interpreted incorrectly by the wrong application. An example of this is as follows: a sending terminal has a DPB and a IM (instant messaging) application. It sets status values: DPB=Closed, IM=Open. In this example both applications would use only status values open and closed. Now if the receiving terminal only has an IM application and it receives both the DPB and IM statuses. If the receiving terminal tries the first status value of DPB it understands it and presents that to the user via the IM application saying that IM application in the presentity's terminal was closed even though it was open.
It has been proposed that where a user wants to obtain presence information about one other user that the user is able to include filters to reduce the data from the presence server, that is the presence information. These filters are able to reduce the data from the presence server to include only parts that are of interest for the user.
The approach where both the tuple identities are used as a filtering criteria by watchers (users requesting presence information) and also the authorization is based on tuple identities has many disadvantages. If for example a user being watched has 4 tuples (T1, T2, T3 and T4) and one watcher is only interested in tuples T2 and T3, the watcher sets filters to allow only tuples T2 and T3 to be notified to him the watched user may then decide for some reason to start showing different values to the particular watcher concerning all tuples. Therefore the watched user creates new tuples T5, T6, T7 and T8 and creates a new access list, which allows the watcher to see tuples T5-T8, but not the tuples T1-T4. But the watcher has set the filtering based on the tuple identity, which means that no tuples are provided to him. This is disadvantageous.
Another disadvantage of using the tuple identities in filtering is that normally the presentity does not want watchers to know that a particular watcher is not allowed to get as detailed information as another watcher, or that the information given to different watcher groups is slightly or totally different from the information given to other watchers.
It is disadvantageous if the filtering settings change every time a watcher's authorization information is changed because of different detail level of information is provided to the watcher. This would be the case if the filtering is based on the unique tuple identities.